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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee GRID (GRID). 
The present document is related to document TS 102 827 [1] (GCM Interoperability Deployment). 



Introduction 



The purpose of the present document is to offer a standard, uniform way of describing grid-based applications, and the 
resources they need. 

When building a grid, one is confronted with several problems, among which: 

• choosing a grid framework, as many are available; 

• when running a grid-enabled application, one must rewrite configuration directives when switching to a 
different grid framework; 

• a grid can be built on widely different hardware infrastructures, from an heterogeneous set of desktop 
machines to a dedicated cluster, or even any combination of those; 

• grid infrastructures can also be very dynamic, it should be easy to add or remove machines, and such changes 
should be transparent to users. 

To simplify this, the GCM Interoperability Deployment standard (TS 102 827 [1]) offers a uniform way to describe grid 
resources. On the application side, the present document describes how various resources can be used by an application, 
providing gridification of applications in a very portable manner. 
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Scope 



The present document describes an XML schema for describing application constraints and resources to be used for 
deploying these applications on distributed and parallel infrastructures, like enterprise and scientific grids or job 
schedulers. 

The present document will help enterprises and laboratories to manage their IT software within large-scale computer 
and telecom infrastructures with the necessary virtualization. 

Its primary audience are users of grid-based applications who will need to write application descriptors so they can run 
them on the grid for their grid. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 102 827: "GRID; Grid Component Model (GCM); GCM Interoperability Deployment". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] Proactive, INRIA. 

NOTE: Available at http://proactive.inria.fr . 

[i.2] MPI Forum. 

NOTE: Available at http://www.mpi-forum.org/docs/ . 

[i.3] Fractal, objectweb. 

NOTE: Available at http : //fractal . obj ect web . org/ . 
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3 Definitions 

For the purposes of the present document, the terms and definitions given in TS 102 827 [1] and the following apply: 

component: abstraction of a software entity with a well-defined interface for both server and client parts 

component model: specification of how components are defined and interact together 

executable: arbitrary program which can be the launch target of an GCM Application Descriptor 

fractal: modular and extensible component model 

NOTE: See http://fractal.objectweb.org/ [i .3] . 

Message Passing Interface (MPI): computer specification and is an implementation that allows many computers to 
communicate with one another 

NOTE: See http://www.mpi-forum.org/docs/ [i.2]. 

Pro Active: Java Grid middleware for parallel, distributed and multi-threaded computing 

NOTE 1: See http://proactive.inria.fr Ti.ll. 

NOTE 2: Pro Active is part of the ObjectWeb/OW2 consortium and developed by INRIA, CNRS and University of 
Nice Sophia Antipolis, with Open Source code under the GPL license. 

4 Overall Structure of the GCM Application Description 



4.1 Principles 



Like a deployment descriptor, an application descriptor is written in XML. Each element of the descriptor is defined as 
a single node, which can have attributes and child nodes. 

Also, see clause 6.1 of TS 102 827 [1]. 

4.2 Overall XML structure 

A deployment descriptor has the following structure: 

< envi ronment > 

<descriptorVariable .../> 
<programVariable .../> 
<descriptorDefaultVariable .../> 
<programDefaultVariable .../> 
<includePropertyFile ...> 

< /environment > 

<application> 

</application> 

<resources> 

<nodeProvider> 
<file .../> 

</nodeProvider> 

</resources> 

The elements must be specified in this order. The < envi ronment > element can be omitted, while the other ones are 
mandatory. 
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The < environment > element is a table of variable names and their values, which is used to give some amount of 
flexibility to the descriptor. 

The <application> element describes the application that will be run on the grid, and the amount of resources it 
will use (the number of processing nodes). 

Finally, the < re source s> element describes the resources made available by the grid, by referencing deployment 
descriptors through <nodeProvider> elements. 

4.2.1 Environment 

The < environments element can have the following children elements: 

• descriptor Variable: the value has to be set in the descriptor, and cannot be specified in the program; 

• descriptorDefault Variable: a default value must be specified in the descriptor. The program has the ability to 
change the value at execution. If the value is changed in the program, then this new value will have precedence 
over the one defined in the descriptor; 

• programVariable: the value must be set in the program, and cannot be specified in the descriptor; 

• programDefault Variable: a default value must be specified by the program as a constant, or computed (based 
on input size, for instance). The descriptor has the ability to change the value. If the value is changed in the 
descriptor, then this new value will have precedence over the one defined in the program; 

• includePropertyFile: read variable definitions from a property file. A property file contains variable 
definitions as "NAME = VALUE" lines, for example: 

variable 1 = value 1; 

variable2 = value2. 

There can be any number of these children elements. They cannot have child elements. 

<descriptorVariable>, <descriptorDef aultVariable> and <programDef aultVariable> have 
two attributes, "name" and "value", each accepting string values. 

<programVariable> only has a single "name" attribute (since it can only be set in the program). 

<includePropertyFile> only has a single "location" attribute. 

EXAMPLE: 

< envi ronment > 

<descriptorVariable name="usertype" value= "admin" /> 
<descriptorDefaultVariable name="username" value="j smith" /> 
<programVariable name="nbNodes" /> 
<programDef aultVariable name="nbJobs" value="10" /> 

<includePropertyFile location="otherVariableDefs .property" /> 
< /environment > 



Application Specification 



The <application> element is the core of the descriptor, as it describes the application which will be run on a 
GCM-described grid. It contains a single child which type determines the kind of application that will be launched on 
the grid. The types currently defined are: 

1) Executable. 

2) Pro Active. 
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5.1 



Executable 



An executable defines an application which is actually a simple command to be run. 
It can have the following child elements: 

• nodeProvider (empty element with a single "refld" attribute): the id of a node provider (defined in the 
< re sources > part). There can be any number of such element; 

• command (command): the command which will be run on the portion of the grid defined by the specified 
node providers. 

This element can have the following attribute: 

• instances (one of "onePerHost", "onePerVM", "onePerCapacity"): the number of instances of the command 
which will be run. 

The < command > element can have the following children (in this specified order): 

• path (path string): the path of the executable; 

• arg (string): the arg string which will be passed to the command. There can be any number of such element; 

• filetransfer (file transfer): the files which should be transferred prior to running the command. 
It can have the following attribute: 

• name (string): name of the executable. If a <path> child element is present, the value of this attribute will be 
appended to the value of the <path> child element. 



(n executableTypejB (lP/E f <][> extends: applicationNodeTypejEh — (■-"-■ J Eh — | nodeProvider |b (Q)b ! 



(n cornrnandTypelEh — ["-"iBi — I path |b /— 

^ — > ^ } \- — I ( □ pathElementTvpe 



K 



relpath ia 
type: pathElementType from: CommonTypes.xsd 



o..» 



\ V string ) b 
| type: string from: XM [Schema, xsd 



[y pararneterTypeV] 
type: parameterType 






@ instances |b — UTJB — (N restricts: xsd: string ) Eh — I ^ onePerHost I 

I ^ onePerVM | 



^ onePerCapacity I 



[7 string 
base: string from: XMLSchema.xsd 



V_ 



(n applicationNodeTypeJ 



Figure 1 
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Example of a call to the "Is" Unix command: 

<executable> 

< command name="ls"> 
<arg>-l</arg> 
<arg>-h</arg> 
<arg>--sort=time</arg> 
<arg>-r</arg> 
</ command > 

<nodeProvider ref id="INRIA_LAN" /> 
</executable> 

5.2 Extension of applicationNodeType (ProActive) 
5.2.1 Overall structure 

The proactiveType is a more complex extension of applicationNodeType than executableType.lt uses the 
technicals ervices and virtualNode XML types as follows: 

<proactive> 

<technicalServices> 
</technicalServices> 

<virtualNode> 

<nodeProvider/> 

</virtualNode> 
<virtualNode> 

</virtualNode> 
</proactive> 

The technicalServices elements specify the set of technical services global to the instance of ProActive. Technical 
Services are described in clause 5.2.3. 

A <virtualNode> element can have the following children: 

• nodeProvider (reference to a node provider): the node provider for this virtual node - see below for 
description; 

• technicalServices (technical service): a technical service specific to the virtual node. There can be any number 
of such child elements. 

A virtualNode element can also have the following attributes: 

• id (string): a string identifying the virtual node; 

• capacity (positive integer): the capacity requested by this virtual node (that is, the total number of nodes it will 
request from the node providers which are associated with it). If not specified, the virtual node gets as many 
node as possible. If multiple virtual nodes without a capacity are defined, a fair share allocation must be 
performed. Virtual nodes with specified capacity must be fulfilled before virtual nodes without a specified 
capacity. 

A <nodeProvider> within a <virtualNode> can only have <technicalServices> child elements. These describe technical 
services specific to the node provider. A <nodeProvider> can also have the following attributes: 

• refid (string): the id of the node provider (as defined in the resources element); 



• 



capacity (positive integer): the capacity of the node provider (that is, the number of nodes which may be 
requested. 
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5.2.2 Definition of proactiveType 

In addition to using standard GCM types, elements of type proactiveType can have the following children: 

• configuration: various configuration parameters. This element can have the following children: 

bootClasspath (simple classpath): the boot classpath for the JVM; 

Java (path string): the path to the Java executable; 

jvmarg (string): arguments passed to the JVM; 

applicationClasspath (classpath): classpath for the application; 

proactiveClasspath (classpath): classpath used to override the standard Pro Active classpath computed 
from its installation location; 

securityPolicy (relative path): path to the Java security policy file; 

proactiveSecurity: security policy for application and runtime. This element has two children: 

■ applicationPolicy (relative path): path to Java security policy file that will be applied on the 
application's objects deployed at runtime, like nodes and active objects; 

■ runtimePolicy (relative path): path to Java security policy file that will be applied on the 
Pro Active Runtime. 

log4jProperties (relative path): path to the Java log4j configuration file; 

userProperties (relative path): path to the Java properties file; 

virtualNode (virtual node): description of a virtual node. There can be any number of such element. 

The <proactive> element can have the following attributes: 

• relpath (path string): the location of the Pro Active installation; 

• base (one of "HOME", "ROOT"): base location of the Pro Active installation: HOME is the user's home 
directory, ROOT is the root directory of the system. 
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Figure 2 



EXAMPLE: 



<proactive base="root" relpath="/usr/local/proactive" > 
<technicalServices> 

<class name= "proact iveservices " > 

<property name="myprop" value="avalue"/> 
</class> 
<class name= " otherservices " > 

<property name="x" value="12"/> 
<property name="y" value="15"/> 
</class> 
</technicalServices> 

<virtualNode id= "master" capacity="l" > 
<technicalServices> 

<class name="vnodeservices"> 

<property name="myprop" value="avalue"/> 
</class> 
</technicalServices> 

<nodeProvider ref id= " INRIA_LAN" > 
<technicalServices> 

<class name="nodeprovidertechservices"> 

<property name="myprop" value="avalue"/> 
</class> 
</technicalServices> 
</nodeProvider> 
</virtualNode> 

<virtualNode id=" slaves" > 

<nodeProvider ref id="INRIA_LAN"/> 
<nodeProvider ref id= " INRIA_CLUSTERS " / > 

</virtualNode> 
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<virtualNode id="slaves2" > 

<nodeProvider ref id="INRIA_LAN"/> 
<nodeProvider ref id= " INRIA_CLUSTERS " / > 

</virtualNode> 

</proactive> 



5.2.3 Technical Services 



A technical service is a non-functional requirement that may be dynamically fulfilled at runtime by adapting the 
configuration of selected resources. Such services are specified with a <technicalServices> element. This 
element holds a sequence of <class> children elements, which themselves hold a sequence of <property> 
elements. 

A <class> element has a single attribute, "name", of type string. A <property> element has two attributes, "name" 
and "value", both of type string. 
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Figure 3 



EXAMPLE: 



<technicalServices> 

<class name="proactiveservice" > 

<property name="myprop" value="avalue"/> 
</class> 
<class name="otherservice"> 

<property name="x" value="12"/> 
<property name="y" value="15"/> 
</class> 
</technicalServices> 



• Technical services can be defined at several levels of the application definition: 
globally; 

for a given virtual node; 
for a given node provider for a virtual node. 
This is better explained with the following skeleton: 

<proactive> 

<technicalServices> 

<class name="proactiveFaultTolerance" > 

<property name=" enable" value="true" /> 
</class> 
</technicalServices> 

<virtualNode> 

<technicalServices> 
<class name= "..."> 

<property name="..." value="..." /> 
</class> 

</technicalServices> 
<nodeProvider> 

<technicalServices> 
<class name= "..."> 

<property name="..." value="..." /> 
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</class> 
</technicalServices> 
</ node Providers 

</virtualNode> 

</proactive> 

5.2.4 Data 

The data tag allows describing the input and output data stores required by an application. Each data store has a unique 
identifier. The default input and output data stores are automatically tagged with the "default" identifier. Grid 
middleware are expected to provide an interface to upload and download data from the remote data stores. This element 
is optional and can appear only once. 

A <data> element can have the following children: 

• inputDefault: The default input location. 

• input: Additional input locations. There can be any number of such children. 

• outputDefault: The default output location. 

• output: Additional output locations. There can be any number of such children. 

Each one of the < inputDefault >, <input>, <outputDef ault>, <output> elements can have the 
following children: 

• remote Access: access URL to this data store. Used for accessing it from remote nodes. URL defines which 
protocol is used to access the data from remote node, and some additional information for protocol like path, 
username, password etc. This element is mandatory and can appear only once. 

• location: describes where the data are physically stored. If specified it allows local access to the data when 
possible. This element is optional. 

A<location> element can have the following attributes : 

• hostname: hostname of host where data are stored. Data can be accessed locally on hostname with that name. 

• path: local path to data. This path is local to host with hostname specified in hostname attribute. 
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Resource Specification 



The <resources> element has no attributes and only contains a sequence of <nodeProvider> elements. There 
can be any number of such elements. 
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Figure 6 
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6.1 



Node Provider 



A <nodeProvider> can have the follow children: 

• file (file): this element can only have a single attribute ("path") which contains the path to the deployment 
descriptor file which the node provider uses. There can be any number of such elements. 

It can also have the following attribute: 

• id (id): a string identifying the Pro Active node provider. 

@ path 



[□ nodeProviderType JD- 
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Figure 7 
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Annex A (normative): 
Schema 



<?xml version="l . 0" encoding="UTF-8" ?> 

<xsd: schema xmlns :xsd="http : //www. w3 . org/2 01/XMLSchema" targetNamespace="urn:gcm: application: 1.0" 

xmlns="urn:gcm: application: 1.0" 

elementFormDefault= "qualified" > 

<xsd:include schemaLocation=" . /CommonTypes .xsd" /> 

<xsd: attribute name="OSAttr" > 
<xsd : simpleType> 

<xsd: restriction base="xsd: string" > 

<xsd : enumeration value= "Unix" ></xsd : enumeration> 
<xsd: enumeration value= "Windows" ></xsd: enumeration> 
</xsd: restriction> 
</xsd: simpleType> 
</xsd: attribute> 

<xsd : attribute name= " PriorityAttr " > 
<xsd : simpleType> 

<xsd: restriction base="xsd: string" > 

<xsd: enumeration value="Low" ></xsd: enumeration> 
<xsd : enumeration value= "Normal " ></xsd : enumeration> 
<xsd : enumeration value= "High" ></xsd : enumeration> 
</xsd: restriction> 
</xsd: simpleType> 
</xsd: attribute> 

<xsd: simpleType name="parameterType" > 

<xsd: restriction base="xsd: string" >< /xsd: restrict ion> 
</xsd: simpleType> 

<xsd : complexType name= " j reType " > 

<xsd : sequence> 

<xsd: element name= "parameter" type="parameterType" /> 

</xsd : sequence> 

<xsd: attribute name="path" type="xsd: string" ></xsd: attribute> 
</xsd: complexType > 

<xsd: complexType name="valueType" > 

<xsd: attribute name="value" type= "xsd: string" /> 
</xsd: complexType > 

<xsd: simpleType name="DataSpacesInputOutputIdType" > 
<xsd: restriction base="idType" > 
<xsd: pattern 
value=" ["/] {1,6} | [ A /] {8, } | [M] [ A /] {6} | ["/] [*e] [ A /] {5} | [ A /] {2} [*f] [ A /] {4} | [ A /] {3} ["a] [ A /] {3} | [ A /] {4} [ 
*u] [ A /] {2} | [ A /] {5} [ A l] [ A /] | [ A /] {6} [ A t] "/> 
</xsd: restriction> 
</xsd: simpleType> 

<xsd: simpleType name="DataSpacesInputOutputIdOrVariableType" > 

<xsd: union memberTypes="DataSpaces Input Output IdType variableRefType"/> 
</xsd: simpleType> 

<xsd: complexType name="namingServiceType" > 

<xsd: attribute name="url" type="xsd: anyURI" use=" required" /> 
</xsd: complexType > 

<xsd : complexType name= " remoteAccessType " > 

<xsd: attribute name="url" type="xsd: anyURI" use=" required" /> 
</xsd: complexType > 

<xsd: complexType name="locationType" > 

<xsd: attribute name=" hostname" type="hostnameOrVariableType" use=" required" /> 

<xsd: attribute name="path" type= "xsd: string" use=" required" /> 
</xsd: complexType > 

<xsd : complexType name= " inputDef aultType " > 
<xsd:all> 
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<xsd: element name=" remote Access" type="remoteAccessType" minOccurs="l" /> 
<xsd: element name=" location" type="locationType" minOccurs=" 0" /> 

</xsd:all> 
</xsd: complexType> 

<xsd : complexType name= " inputType " > 
<xsd : complexContent > 

<xsd : extension base= " inputDef aultType " > 

<xsd: attribute name="id" use=" required" 
type="DataSpacesInputOutputIdOrVariableType"/> 
</xsd : extension> 
</xsd : complexContent > 
</xsd: complexType > 

<xsd : complexType name= " outputDef aultType " > 
<xsd:all minOccurs="l" > 
<xsd: element name="remoteAccess" type="remoteAccessType" minOccurs="l" /> 
<xsd: element name=" location" type="locationType" minOccurs=" 0" /> 

</xsd:all> 
</xsd: complexType > 

<xsd : complexType name= " outputType " > 
<xsd : complexContent > 

<xsd: extension base="outputDef aultType" > 

<xsd: attribute name="id" type="DataSpacesInputOutputIdOrVariableType" 
use= " required" / > 

</xsd : extension> 
</xsd : complexContent > 
</xsd: complexType > 

<xsd : complexType name= " dataType " > 
<xsd : sequence> 

<xsd: element minOccurs="0" maxOccurs="l" name="namingService" type="namingServiceType" 
/> 

<xsd: element minOccurs=" 0" maxOccurs="l" name= " inputDef ault" type= "inputDef aultType "/> 

<xsd: element minOccurs=" 0" maxOccurs= "unbounded" name=" input" type=" inputType" /> 

<xsd: element minOccurs=" 0" maxOccurs="l" name= "outputDef ault " type= "outputDef aultType "/> 

<xsd: element minOccurs=" 0" maxOccurs= "unbounded" name= "output " type= "outputType" /> 
</xsd : sequence> 
</xsd: complexType > 

<xsd : complexType name= " technicalServiceType " > 
<xsd : sequence> 

<xsd: element name=" class" maxOccurs= "unbounded" > 
<xsd : complexType > 
<xsd : sequence> 

<xsd: element name= "property" maxOccurs= "unbounded" > 
<xsd : complexType > 

<xsd: attribute name="name" type="xsd: string" use=" required" /> 
<xsd: attribute name= "value" type="xsd: string" use=" required" /> 
</xsd: complexType > 
</xsd: element > 
</xsd : sequence> 

<xsd: attribute name="name" type="xsd: string" use=" required" /> 
</xsd: complexType > 
</xsd: element > 
</xsd : sequence> 
</xsd: complexType > 

<xsd: complexType name="nodeProviderType" > 
<xsd : sequence> 

<xsd: element name="file" maxOccurs= "unbounded" > 
<xsd : complexType > 

<xsd : attribute name= "path" type= "pathElementGeneralType " ></xsd : attribute> 
</xsd: complexType > 
</xsd: element > 
</xsd : sequence> 

<xsd: attribute name="id" type="idType" ></xsd: attribute> 
</xsd: complexType > 

<xsd: complexType name="virtualNodeType" > 
<xsd : sequence> 

<xsd: element name="technicalServices" type=" technicalServiceType" minOccurs=" 0" /> 
<xsd: element name="nodeProvider" minOccurs=" 0" maxOccurs= "unbounded" > 
<xsd : complexType > 
<xsd : sequence> 

<xsd : element name= " technicalServices " type= " technicalServiceType " 
minOccurs="0" /> 
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</xsd : sequence> 

<xsd: attribute name="ref id" type="idType" use=" required" /> 
<xsd: attribute name=" capacity" type="xsd:nonNegativeInteger" /> 
</xsd: complexType> 
</xsd: element > 
</xsd : sequence> 

<xsd: attribute name="id" type="xsd: string" use= " required" ></xsd: attribute> 
<xsd : attribute name= " capacity" type= "xsd : nonNegativelnteger " ></xsd : attribute> 
</xsd: complexType> 

<xsd : complexType name= " commandType " > 
<xsd : sequence> 

<xsd: element name="path" type="pathElementType" minOccurs=" 0" /> 

<xsd:element name="arg" type= "xsd: string" minOccurs=" 0" maxOccurs= "unbounded" /> 
</xsd : sequence> 

<xsd : attribute name= "name " type= "parameterType " ></xsd : attribute> 
</xsd: complexType > 

<xsd: complexType name="applicationNodeType" abstract="true" ></xsd: complexType> 

<xsd: complexType name="proactiveType" > 
<xsd : complexContent > 

<xsd: extension base="applicationNodeType" > 
<xsd : sequence> 

<xsd: element name="technicalServices" type="technicalServiceType" minOccurs=" 0" 

<xsd: element name=" configuration" minOccurs=" 0" > 
<xsd : complexType > 
<xsd : sequence> 

<xsd: element name="bootClasspath" type="pathType" minOccurs=" 0" /> 
<xsd: element name="java" type="pathElementType" minOccurs="0" 



maxOccurs= 



minOccurs="0" maxOccurs="l" /> 

minOccurs=" 0" maxOccurs="l" /> 

minOccurs="0" maxOccurs="l" /> 

minOccurs="0" maxOccurs="l" /> 



<xsd: element name=" jvmarg" minOccurs=" 0" maxOccurs= "unbounded" > 

<xsd : complexType > 

<xsd: attribute name="value" type= "xsd: string" /> 

</xsd: complexType > 
</xsd: element > 
<xsd: element name="applicationClasspath" type="classpathType" 

<xsd: element name="proactiveClasspath" type="classpathType" 

<xsd: element name="securityPolicy" type="pathElementType" 

<xsd: element name="log4j Properties" type="pathElementType" 

<xsd: element name="userProperties" type="pathElementType" 



minOccurs="0" maxOccurs="l" /> 

</xsd : sequence> 
</xsd: complexType > 
</xsd: element > 

<xsd: element name="virtualNode" type="virtualNodeType" maxOccurs= "unbounded" > 
<xsd : unique name= "nodeProviderConstraint " > 

<xsd : selector xpath= "nodeProvider " ></xsd : selector> 
<xsd: field xpath="@ref id" ></xsd: f ield> 
</xsd : unique> 
</xsd: element > 

<xsd: element name="data" type="dataType" minOccurs="0" maxOccurs="l" /> 
</xsd : sequence> 

<xsd: attribute name="relpath" type="pathElementGeneralType" use=" required" /> 
<xsd: attribute name="base" use= " required" > 
<xsd : simpleType> 

<xsd: restriction base="xsd: string" > 
<xsd: enumeration value="home" /> 
<xsd: enumeration value="root" /> 
</xsd: restriction> 
</xsd: simpleType> 
</xsd: attribute> 
</xsd : extension> 
</xsd : complexContent > 
</xsd: complexType > 

<xsd : complexType name= " executableType " > 
<xsd : complexContent > 

<xsd: extension base="applicationNodeType" > 
<xsd : sequence> 

<xsd : element name= " command" type= " commandType " ></xsd : element > 
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<xsd: element name =" node Provider" maxOccurs= "unbounded" > 
<xsd : complexType> 

<xsd: attribute name="refid" type="xsd: string" use=" required" /> 
</xsd: complexType> 
</xsd: element > 
</xsd : sequence> 

<xsd : attribute name= " instances " > 
<xsd : simpleType> 

<xsd: restriction base="xsd: string" > 

<xsd : enumeration value= "onePerHost " ></xsd : enumeration> 
<xsd : enumeration value= "onePerVM" ></xsd : enumeration> 
<xsd: enumeration value="onePerCapacity" ></xsd: enumeration> 
</xsd: restriction> 
</xsd: simpleType> 
</xsd: attribute> 
</xsd : extension> 
</xsd : complexContent> 
</xsd: complexType> 

<xsd: element name="abstractApplicationElement " type="applicationNodeType" /> 

<xsd: element name=" executable" type="executableType" 
substitutionGroup="abstractApplicationElement" /> 

<xsd: element name= "proactive" type="proactiveType" 
substitutionGroup="abstractApplicationElement" /> 

<xsd: complexType name="applicationType" > 

<xsd : sequence> 

<xsd: element ref ="abstractApplicationElement " maxOccurs="l" minOccurs="l" ></xsd: element > 

</xsd : sequence> 
</xsd: complexType > 

<xsd : complexType name= " resourcesType " > 
<xsd : sequence> 

<xsd: element name="nodeProvider" type="nodeProviderType" minOccurs="0" 
maxOccurs= "unbounded" ></xsd: element > 
</xsd : sequence> 
</xsd: complexType > 

<xsd: complexType name ="GCMAppli cat ionType" > 
<xsd : sequence> 

<xsd: element name= "environment" type="environmentType" minOccurs=" 0" /> 
<xsd: element name= "application" type="applicat ionType" minOccurs="l" 
maxOccurs="l" ></xsd: element > 

<xsd: element name=" resources" type=" resourcesType" minOccurs="l" 
maxOccurs= " 1 " ></xsd : element> 
</xsd : sequence> 
</xsd: complexType > 

<xsd: element name="GCMApplication" type= "GCMApplicat ionType " > 
<!-- resource providers ref id/id key correctness --> 
< ! -- --> 
<xsd : key name= " idnodeProviders " > 

<xsd: selector xpath="resources/nodeProvider" /> 

<xsd: field xpath="@id" /> 
</xsd:key> 
<xsd : keyref name= " ref IdKeynodeProvider " ref er= " idnodeProviders " > 

<xsd: selector xpath="application/executable/nodeProvider" ></xsd: selector> 

<xsd: field xpath="@ref id" ></xsd: f ield> 
</xsd : keyref > 
<xsd : keyref name= " ref IdKeynodeProvider2 " ref er= " idnodeProviders " > 

<xsd: selector xpath="application/proactive/virtualNode/nodeProvider" ></xsd: selector> 

<xsd: field xpath="@ref id" ></xsd: f ield> 
</xsd : keyref > 
</xsd: element > 

</xsd: schema> 
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Annex B (informative): 

Example of application descriptor 

<?xml version="l . 0" encoding="UTF-8" ?> 

<GCMApplication 

xmlns= "urn: gem: application: 1.0" 

xmlns :xsi="http : //www. w3 . org/2 01/XMLSchema- instance" 

xsi : schemaLocation="http : //www-sop . inria . f r/oasis/ProActive/schemas 

http : //proactive . inria . f r/schemas/gcm/1 . O/ApplicationDescriptorSchema .xsd" > 

<application> 

<proactive relpath="Scratch/ProActive/" > 

<conf iguration> 

<java relpath="myApps/ Java/bin/ Java" /> 
<proactiveClasspath> 

<pathElement base="proactive" 

relpath="lib/log4 j . jar" /> 
<pathElement base="proactive" 

relpath="lib/fractal. jar" /> 
<pathElement base="home" 

relpath="myApps/ganymed-ssh. jar" /> 
</proactiveClasspath> 
<appli cat ionClas spat h> 

<pathElement relpath="myApps/nqueens . jar" /> 
</applicationClasspath> 
<securityPolicy base=" proactive" 

relpath= " config/ security . policy" / > 
<log4j Properties base="home" relpath="log4 j .properties" /> 
</conf iguration> 

<virtualNode id= "master" capacity="l" > 

<nodeProvider ref id="COMPANY_LAN" /> 
</virtualNode> 

<virtualNode id=" slaves" capacity="max" > 
<nodeProvider ref id="COMPANY_LAN" /> 
</virtualNode> 

<data> 

<inputDefault> 

<remoteAccess url="http : //remotehost . tld/path/dir/" /> 
</inputDef ault> 

< input id=" images "> 

<remoteAccess url="f tp : //san. tld/path/images/" /> 
<location hostname="san. tld" path="/user/data/images/" /> 

</ input > 

<outputDef ault> 

<remoteAccess url="scp : //user@f rontend/output/" /> 
</outputDefault> 
</data> 

</proactive> 
</application> 

<resources> 

<nodeProvider id="COMPANY_LAN" > 

<file path= " deployment .xml" /> 

</nodeProvider> 
</resources> 

</GCMApplication> 
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